Importance of Getting Entire Team Involved in Estimation

I’ve never been a huge fan of horror movies. But I have always liked Halloween, especially as a kid. I loved dressing in a scary costume and trying to frighten my friends or other trick-or-treaters. And I admit to getting a bit of a thrill from walking through a well executed haunted house.

But, there are aspects to every agile transformation that can send a shiver down a spine--and those moments are not quite so thrilling. So let’s take the fear factor away from five things that might make you want to run for cover along your agile journey--first by naming them and then by talking about why they aren’t so scary once you understand how they work.

Eeek! Agile Has No Design Phase!

Architects and senior tech people are often frightened by the idea that there’s no design phase in agile. While it’s true that agile teams shun an upfront design phase, that does not mean that design doesn’t occur.

Design on an agile project is characterized by two attributes: it is both emergent  and intentional. An emergent design is one that comes into existence over time. Rather than being done all upfront in a single phase, design is an ongoing activity. The design emerges through the creation of the software.

But design is also intentional. This means the design does not emerge randomly. Design is guided by the intent of the senior technical people on a project or perhaps even someone in a designated architect role.

If the senior technical people are concerned about a particular part of the system, the product owner should prioritize a product backlog item or two in that area. This will allow the team to explore that part of the system by building some small part of that system. Doing so will help identify the appropriate design in that area.

Allowing design to emerge guided by the intent of the team will reduce the terror of there being no design phase in agile.

Help! I'll Become a Generalist.

A common myth that has persisted since the earliest days of agile is that agile teams don’t value specialists and want everyone to become a generalist. This is frightening to many people for two reasons: First, no one enjoys all types of work equally and second because of the concern it could impact future employability if someone can do four things adequately instead of one thing extremely well.

The idea that everyone becomes a generalist on an agile team is completely false. If I’m coaching a team that has the world’s greatest JavaScript wizard, I’m going to want that superstar doing amazing things in JavaScript, not learning how to become a DBA.

Yes, agile teams value members who have multiple skills--the tester who can also write some JavaScript, for example. One of the easiest ways to balance the amount of work between two skills is to have someone who can do either type of work. If, for example, your team finds it hard to balance the amount of work in an iteration between programmers and testers, having someone who is adept at both coding and testing can solve that problem.

A goal in agile is the formation of cross-functional teams, which means the team has all skills needed to produce a finished, working deliverable within the iteration. Doing that does not require each person to have all the skills of a cross functional team.

If the thought of becoming a generalist makes your hair curl, understanding that a cross-functional team still allows for specialists should put your mind at ease.

Oh No! We Can’t Plan or Predict Dates!

Management is often chilled to the bone by the idea that an agile team can’t plan or predict dates further ahead than the current iteration or sprint.

Fortunately, this does not need to be the case.

Yes, agile teams give up the false comfort of overly planned projects with intricately drawn Gantt charts showing a precise completion date way in the distant future. But that does not mean agile teams are unable to make plans or predict future delivery dates or scope.

A huge benefit of agile is that every iteration the team turns the crank on the entire development process. That is, they take an idea usually expressed as nothing more than a simple user story, and they full implement that feature. This means that every few weeks, a team can measure its progress: They can know how much they got done.

Contrast this with a traditional development projects, perhaps one with an analysis phase, a design phase, a coding phase and, finally, a testing phase. When that team measures its progress over a period of time, they are measuring only how fast they are at doing one (or perhaps two) types of work. How fast a team is at doing design says nothing of how fast the team will be at coding and testing.

The key with agile planning is embracing the uncertainty--admitting that it’s impossible to know all the functionality that will be built before starting the project--and then adjusting for that in a variety of possible ways. When teams combine this realization with the ability to actually measure the amount of work done every iteration, it leads to reliable planning, which should calm the nerves of a management team daunted by the prospect of having no predictability.

Yikes! I Won't Have a Job!

The prospect of transitioning a team or company to agile is enough to scare the pants off some managers who are concerned they won’t have a job after the transition is complete.

This is understandable. It would be dismaying to start a transition effort aimed at helping a company knowing that it may make your role superfluous.

However, I can clearly say that I have never helped a company adopt agile and then seen that company say, “OK, we no longer need people with job title such-and-such. They’re all terminated.” It just doesn’t happen. Sure, a company may decide a specific job title is no longer needed or appropriate. But the individuals with those titles still have jobs. And in most cases, I believe they end up with better, more focused jobs. With that being said, it is true that some people will end up with less direct control over people or decisions and they may find that frustrating, even to the point of leaving the company.

But because I have never seen significant layoffs of any role or skill as part of transitioning to agile, I believe this fear is as misplaced as that of a zombie apocalypse.

Zoinks! Scrum Has Too Many Meetings!

Like many people, I really hate meetings. In fact, it’s largely why I do what I do. Most days I have no meetings at all. Pure bliss.

But even I can acknowledge that some meetings are important and useful. And that includes the four standard meetings of Scrum: the sprint planning meeting, the daily scrum, the review, and the retrospective.

The thought of all these meetings, however, can send some people into a cold sweat.

Here’s the problem with Scrum meetings--they have names. When something has a name, it’s easier to attack. In my experience, many teams who adopt Scrum had more meetings before Scrum. But the meetings didn’t have names and were mostly ad hoc meetings called to resolve specific issues.

Here’s an experiment I like and that you can easily do to see if you’re having significantly more meetings with Scrum. Randomly pick a month on your calendar from before you started adopting an agile approach. Open that month up in your calendar software and add up the time spent in meetings. Then add up the average time in your Scrum meetings and see how they compare.

Based on my experience, you might well be surprised by the results. But because those pre-agile meetings were not recurring, regular meetings, they didn’t have names and so they don’t stick out in our memories the same way a named meeting, like “Sprint Planning,” does.

The key for overcoming the terrorizing thought of too much time spent in meetings is keeping the meeting short. Occasionally I’ll work with a team that I need to encourage to spend more time in a certain meeting. But most teams spend too much time in each of the standard meetings. Once they find ways to shorten them, those meetings should no longer frighten us out of our wits.

Relax...those Ghosts and Ghouls Aren’t Real.

While it can be fun to walk through a haunted house or dress in a scary costume, most of us can easily remember that it’s all make-believe. Those ghosts, ghouls, vampires, werewolves, and crazed lunatics with chainsaws aren’t real.

And neither are the five agile legends I’ve outlined here. And while no one can be faulted for being afraid at first, education and experience will pull the mask off the myths, leaving us reassured rather than unnerved.

What Have You Been Afraid Of?

What part of transitioning to agile did you find the most scary? How did you overcome your fear? Please share your thoughts in the comments section below.

A well-established best practice is that those who will do the work, should estimate the work , rather than having an entirely separate group estimate the work.

But when an agile team estimates product backlog items, the team doesn’t yet know who will work on each item. Teams will usually make that determination either during iteration (sprint) planning or in a more real-time manner in daily standups.

This means the whole team should take part in estimating every product backlog item. But how can someone with a skill not needed to deliver a product backlog item contribute to estimating it?

Before I can answer that, I need to briefly describe Planning Poker, which is the most common approach for estimating product backlog items. If you are already familiar with Planning Poker, you can skip the next section.

Planning Poker

Planning Poker is a consensus-based, collaborative estimating approach. It starts when a product owner or key stakeholder reads to the team an item to be estimated. Team members are then encouraged to ask questions and discuss the item so they understand the work being estimated.

Each team member is holding a set of poker-style playing cards on which are written the valid estimates to be used by the team. Any values are possible, but it is generally advisable to avoid being too precise. For example, estimating one item as 99 and another as 100 seems extremely difficult as a 1% increase in effort seems impossible to distinguish. Commonly used values are 1, 2, 3, 5, 8, 13, 20, 40, and 100 (a modified Fibonacci sequence) and 1, 2, 4, 8, 16, and 32 (a simple doubling of each prior value).

Once the team members are satisfied they understand the item to be estimated, each estimator  selects a card reflecting their estimate. All of the estimators then reveal their cards at the same time. If all the cards show  the same value, that becomes the team’s estimate of the work involved. If not, the estimators discuss their estimates with an emphasis on hearing from those with the highest and lowest values.

If you aren’t familiar with estimating product backlog items this way, you may want to read more about Planning Poker  before continuing.

How Can Someone Participate Without the Needed Skills

Equipped with a common understanding of Planning Poker, let’s see how a team member can contribute to estimating work that they cannot possibly be involved in. As an example, consider a database engineer who is being asked to estimate a product backlog item that will include front-end JavaScript and some backend Ruby on Rails coding, and will then need to be tested.

How can this database engineer contribute to estimating this product backlog item?

There are three reasons why it’s possible--and desirable.

1. Planning Poker Isn’t Voting

When playing Planning Poker, participants are not voting  on their preferred estimate. The team will not  settle on the estimate that gets the most votes. Instead, each estimator is given the credibility they deserve. If one programmer wrote the original code that needs to be modified and happened to be in that same code a couple of days ago, the team should give more credence to that programmer’s estimate than to the estimate of a programmer who has never been in this part of the system.

This means that each team member can estimate, but that the team will weigh more heavily the opinions of those more closely aligned with the work.

2. Estimates Are Relative and That’s Easier

In Planning Poker, the estimates created should be relative  rather than absolute estimates. That is, a team will say things like, “This item will take twice as long as the other item, but we can’t estimate the actual number of hours for either item.”

For example, this blog post contains one illustration. I provided my artist with a short description of what I had in mind for an image and he created the illustration. Most of my blog posts have one title illustration. Even though I have no artistic skill, I could estimate the work to create those illustrations as about equal each week.

Sure, some illustrations are more involved, and others can reuse a few elements from a past illustration. But most are close enough that I could estimate them as taking the same effort.

But some blog posts have two images. Even though I have no design skills at all, I’m willing to say that creating two images will take about twice as long as creating one image.

So a tester is not being asked to estimate how many hours it will take a programmer to code something. Instead the tester is estimating coding that thing relative to other things.

That can still be hard but relative estimates are easier than absolute estimates. And remember that because of point one above, the person whose skills may not be needed on the story will not be given as much credibility as someone whose skills will be used.

3. Everyone Contributes, Even If They Don’t Estimate

I want everyone on the team to participate in an estimating meeting. But that does not mean everyone estimates every item.

Despite relative estimating being easier than absolute estimating, there will still be times when someone will not be able to estimate a particular product backlog item. This might be because the person’s skills aren’t needed on that item. But that person may still be able to contribute  to the discussion.

Sometimes the person whose skills are not needed on a given product backlog item will be the most astute in asking questions about the item, uncovering overlooked assumptions, or in seeing work that others on the team have missed.

For example, a database developer whose skills are not needed to deliver a product backlog item may be the one who remembers that:

The team promised to clean up that code the next time they were in it

There is an impact on reports that no one has considered

That when the team did a similar story a year ago it took much longer than anyone anticipated

and so on. The database developer may know these things or ask these questions even if unable to personally estimate their impact on the work.

A Few Examples

To provide a few examples, let’s return to role of a database engineer in estimating a product backlog item that has no database work. Here are some examples of things that team member might say that would add value to estimating that product backlog item:

• “I’m holding up this high estimate because this sounded like a lot of effort to code. It sounded like about twice as much as this other backlog item.”
  
  In this case, the database engineer is making a relative assessment of effort. This will presumably be based on things said by coders. In some cases, the database engineer may be wrong in that assessment. But that doesn’t mean the person’s opinion is always without merit. The database engineer’s opinion should be given the merit it deserves (which may be great or little).


• “Are you sure it’s that much work? I thought two sprints ago, you programmers were going to refactor that part of the system. If that happened, isn’t this easier now?”
  
  Here the database engineer is bringing up information that others may not have recalled or considered. It may or may not be of value. But sometimes it will be.


• “Are you sure it’s not more work than that? Have you considered the need to do this and that?”
  
  In this case, the database engineer is pointing out work that the others may have overlooked. If that work is significant, it should be reflected in the estimate.

When Everyone Participates, It Increases Buy In

There’s one final reason why I suggest the whole team participate when estimating product backlog items, especially with a technique such as Planning Poker: Doing so increases the buy in felt by all team members to the estimates.

When someone else estimates something for you or me, we don’t feel invested in that estimate. It may or may not be a good estimate. But if it’s not, that’s not our fault. We will do much more to meet an estimate we gave than one handed to us.

We want everyone on a team to participate in estimating that team’s work. You never know in advance who will ask the insightful questions about a product backlog item. Sometimes it’s one of the team members who will work on that item. But other times those questions come from someone whose skills are not needed on that item.

So while not every team member needs to provide an estimate for each item, every team member does need to participate in the discussion surrounding every estimate. Teams do best when the whole team works together for the good of the product, from estimation through to delivery.

What Has Your Experience Been?

What has your experience been with involving the whole team in estimating product backlog items? Have you found it beneficial to have everyone participate even though not everyone has skills needed on each item?

A common problem with user stories is how to add the right amount of detail to a story so that it is ready to be brought into an iteration or sprint.

It's an important balancing act. Bring a story into an iteration before it is sufficiently understood and there will be too many open issues for the team to complete it within the iteration. But try to resolve every open issue and add every little detail to a story and you end up with functionality that takes far too long to make it into the hands of users.

Like Goldilocks and the bears, we don't want stories with too little or too much detail. We want detail that is just right.

And we want that detail at just the right time, too. When  detail is added to a user story is every bit as important as how much  is added.. If details are added needlessly far ahead of when the story is worked on, there is a strong chance that some of those details will be wrong.

Trying to resolve all open issues in advance is costly. It can lead to rework if wrong answers are provided. It can lead to longer time-to-market as team members are stalled waiting for answers. It can also lead to a loss of creativity as programmers are merely told exactly how to implement something.

Not Everything Needs to Be Known Before Starting

When thinking about working on a user story, it is useful to realize that the team doesn't need to know everything before it starts a story.. All open questions need to be answered before a story is finished , but not all need to be answered before the story is started.

As an example, suppose a team is working on a story such as, “As a user, I am locked out after n failed attempts to log in.” The team clearly needs to know the number of failed attempts before they call this story done. But both programming and testing can begin without that answer.

What You Can Do Right Now

If you or your team has ever struggled to include the right amount of detail at the right time, I’ve created a free 13-minute training video to help.

In it, you get concrete advice on how you can know the right amount of detail to add to each user story. I’ll also share with you the one question I ask in every retrospective to make sure detail is being added at the right time and in the right amount.

Watch now and see how to add the right amount of detail at the right time.

This is the third in a series of videos I’ve created to help you write better user stories. But it will only be available through 11 October. So if you’re like the majority of agile teams who struggle with adding the right amount of detail, go watch the video right now. I know you’ll find it helpful.

What’s Your Experience?

Does your team sometimes struggle to add the right amount of details at the right time to user stories? How do you ensure stories are neither too vague nor too detailed? After you watch the video lesson, please share your thoughts in the comments section below.

Isn’t it extraordinary that something as fundamental as emotion is only just finding its place in our world? Recent advances in understanding how human brains work have given us a new focus on emotion, showing us how it directs and influences us.

Skills to Build Relationships

“The trouble is that education is so academic,” Catherine begins, “It’s based on knowledge and not the ability to build relationships.”  Aga too had highlighted that the skills needed in today’s AI driven world are those that differentiate us from robots. Knowledge can be accessed online or programmed in but thriving in a world that’s in a constant state of fast change needs the ability to collaborate and communicate effectively.

Research indicates that emotional intelligence is twice as important as IQ when it comes to getting where we want to go in life, and yet emotion is still largely ignored by our education system. “The gap is that we don’t learn about emotions at school,” Catherine continues, “Actually, teacher training generally doesn’t cover emotions at all. It’s a real omission. Emotions are the route to self awareness and self knowledge, and these things are critical for success.

 “In schools emotions tend to be branded as a bit of an inconvenience. Children are encouraged to control their emotions, but they are not empowered to understand and respond to them. Think about it, a teacher may well implore a child not to cry, or they may say that a child shouldn’t be angry and apply correctives to prevent it. We are not taught to give space to emotion.”

Emotions as Warning Lights

Catherine uses an analogy of a car to illustrate how she sees the role of emotions. “If your car flashes a red warning light that the oil is low, you may find that very irritating. It doesn’t make you unplug the light to stop the flashing. You consider what is causing the alarm and most likely you then attend to the car’s needs, giving it what it is missing to restore the balance to its operations.

“This is the role of emotions in communication. They are our warning light system, and we ignore them at our peril.

“We are told that good communication comes from gaining congruence between what we think and what we say. Congruence is also needed with what we feel. We cannot ignore that bit.”

Telling a child “There is nothing to be scared of” teaches them to mistrust their own emotions. Generation Agile points to the need to build children’s confidence so that they trust their instincts and feel empowered to share ideas and innovate. Just consider how the common retort “Never answer back” may sow seeds that prevent the transparent sharing of ideas and collaboration in the workplace.

“Ultimately,” Catherine concludes, “We need to educate children for a world that we won’t live in. Change is so fast that we can’t yet imagine the challenges that they will face and the context that they will live in. Today’s children will be tomorrow’s workers, and need the skills now to be confident communicators, to be able to collaborate and explore new things without fear.”

Humans are social animals. The way we communicate, collaborate, and explore and innovate has defined our evolution so far. It will define our future too. No surprise then that Communication is one of the 3Cs of Agile Leadership and a core principle of Agile Project Management.